This is an experiment to further reduce anywidget's dependency on @jupyter-widgets/base (and thus Backbone). The idea is that by managing the comm ourselves, we can more readily implement adapters for other popular frontend frameworks without the overhead/dependency of another framework. Additionally, this would allow us to configure things like serializers custom serializers.

However, it's increasingly clear just how coupled classic Backbone-based widgets are with the rest of the Jupyter ecosystem. This PR is kind of massive, so I'm not sure how viable it is. There are many rough edges with trying to understand the boundaries between widget manager and DOMWidgetView/DOMWidgetModel, and expected APIs.

So far my approach has been manually looking at the ipywidgets source code and only exposing public APIs on the Model and View that are used by the WidgetManager. We will only go forward with this PR if we are able to faithfully implement anywidget's current API.

My hope is that we can have different, "mode"s for anywidgets, one of which could be more low-level and for front-end framework authors. For example, the existing Backbone widgets could be implemented with this like:

export default {
  mode: "comm",
  comm_open({ comm, attributes }) {
    let model = new Backbone.Model({ attributes });
    comm.on_msg((msg) => /* update model */);
    comm.on_close(() => /* destroy model */);
    model.save_changes = () => {
      comm.send({ content: { method: "update", /* ... */ });
    }
    return model;
  },
  initialize({ model }) {
  
  },
  render({ model, el }) {

  }
}